Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Verbosity cleanup and reduced warnings/printouts #636

Open
wants to merge 38 commits into
base: main
Choose a base branch
from

Conversation

jkirk5
Copy link
Contributor

@jkirk5 jkirk5 commented Dec 26, 2024

Summary

Made a variety of updates related to Aviary's printouts and giving users more control over them, as well as some related housekeeping items while I was looking at that part of the code.

Printouts

  • Overhauled the pyoptsparse and optimizer printouts to provide less information (mostly unneeded/redundant with reports) across the board for all verbosities except DEBUG.
  • Eliminated unnecessary openmdao and dymos printouts.
  • Added a number of verbosity checks on other print statements throughout Aviary (not comprehensive).
  • Tweaked a number of aircraft models to avoid preprocessor warnings about ambiguous inputs (such as providing NUM_ENGINES but not NUM_WING_ENGINES (not comprehensive).

Verbosity

  • Verbosity can now be set independently of what is in the .csv or AviaryValues object when using the Python interface (L1 or L2) as well as from the CLI
    • run_aviary() now has a verbosity argument which overrides whatever is in the aircraft data. Can be passed via CLI.
    • Relevant methods in method_for_level2.py have optional verbosity arguments which override any other verbosity sources for that method call only. In case you want to run a specific step with higher/lower verbosity when using L2.
  • Switched a large number of tests to QUIET verbosity, including all benchmark tests.
  • The default optimizer for AviaryProblem is now IPOPT instead of SNOPT.
  • Default verbosity now pulls from metadata instead of being hardcoded (still BRIEF).

Bugfixes

  • AviaryProblems now uses openmdao default problem name when given an AviaryValues, instead of trying to name it off of the filename Path().stem.

All of methods_for_level2.py got the autoformat treatment since I touched a bunch of pieces of it - makes for a messy diff, but this file was very inconsistently styled, IMO it needed to be done.

Related Issues

  • Resolves #

Backwards incompatibilities

API changes - Level 2

  • run_aviary(): renamed aircraft_filename argument to aircraft_data to reflect capability to provide an AviaryValues object instead of a filepath.

New Dependencies

None

@jkirk5 jkirk5 changed the title Verbosity cleanup roundl;i' Verbosity cleanup round Dec 26, 2024
@jkirk5 jkirk5 changed the title Verbosity cleanup round Verbosity cleanup and reduced warnings/printouts Dec 27, 2024
@@ -131,6 +131,8 @@ dmypy.json

# Test and spec generated
reports/
aviary/reports/
*.openmdao_out
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just want to make sure you know about the openmdao clean command, for cleaning up all of these directories.
https://openmdao.org/newdocs/versions/latest/other_useful_docs/om_command.html#openmdao-clean

@@ -1,2 +1,21 @@
phase_info = {'pre_mission': {'include_takeoff': True, 'optimize_mass': True}, 'climb_1': {'subsystem_options': {'core_aerodynamics': {'method': 'computed'}}, 'user_options': {'optimize_mach': True, 'optimize_altitude': True, 'polynomial_control_order': [1, 2], 'use_polynomial_control': True, 'num_segments': [1], 'order': 1, 'solve_for_distance': True, 'initial_mach': (1, None), 'final_mach': (2, None), 'mach_bounds': (
(0.98, 2.02), None), 'initial_altitude': (1, None), 'final_altitude': (2, None), 'altitude_bounds': ((0.0, 502), None), 'throttle_enforcement': 'path_constraint', 'fix_initial': True, 'constrain_final': True, 'fix_duration': False, 'initial_bounds': ((0.0, 0.0), None), 'duration_bounds': ((0.5, 1.5), None)}, 'initial_guesses': {'time': ([1, 1], None)}}, 'post_mission': {'include_landing': True, 'constrain_range': True, 'target_range': (514.5, None)}}
phase_info = {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This file is proving to be a problem. I think we need it for some glue stuff, but it is auto-generated, so always has to be fixed every time we run the docs.

@@ -223,50 +223,9 @@
"\n",
"To find information about a variable (e.g. description, data type, etc.), users should read the [Variable Metadata Doc](../user_guide/variable_metadata).\n",
"\n",
"There are special rules for the mapping from the input file variable names to the metadata. For example, variable `aircraft:wing:aspect_ratio` in `aircraft_for_bench_GwGm.csv` is mapped to `Aircraft.Wing.ASPECT_RATIO` in `aviary/variable_info/variable_meta_data.py`. So, the first part (e.g., `aircraft` or `mission`) is mapped to the same word but with the first letter capitalized (e.g., `Aircraft` or `Mission`). The third word is all caps (e.g., `ASPECT_RATIO`). The middle part (e.g., `wing`) is a little more complicated. In most cases, this part capitalizes the first letter (e.g., `Wing`). The following words have special mappings:\n",
"Variable names may be differently within the code from how they are formatted inside OpenMDAO components and in input files and outputs. For example, variable `aircraft:wing:aspect_ratio` in `aircraft_for_bench_GwGm.csv` is mapped to `Aircraft.Wing.ASPECT_RATIO` in `aviary/variable_info/variable_meta_data.py`. This is because OpenMDAO requires variable names to be strings, but for developer convenience those strings are mapped to Python classes and attributes. The top-level and sub-categories have capitalized first letters, and the final variable name is always in all-caps. For more information on Aviary's variable hierarchy, see the [Variable Hierarchy doc](../user_guide/variable_hierarchy.ipynb).\n",
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

wording : "may be differently..." --> "may appear differently..."

inertia_factor[i] = 1 - bte / bt * pod_mass[i] / gross_mass
inertia_factor_i = 1 - bte / bt * pod_mass[i] / gross_mass
# avoid passing an array into specific index of inertia_factor
inertia_factor[i] = inertia_factor_i[0]
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It doesn't look like this should ever become a vector, so if it does, then there is something that should be fixed on one of the variables.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good point. I did some digging and somehow gross mass input is a vector, despite being set as a float in do_validation_tests.py (through prob.set_val()). Not sure how this is happening...

@@ -217,7 +217,7 @@
'num_segments': 1,
'order': 3,
'fix_initial': False,
'EAS_target': (250, 'kn'),
'EAS_target': (150, 'kn'),
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Kind of some big changes to the turboprop mission.

@@ -26,11 +26,15 @@
from aviary.mission.flops_based.phases.build_landing import Landing
from aviary.mission.flops_based.phases.build_takeoff import Takeoff
from aviary.mission.twodof_phase import TwoDOFPhase
from aviary.mission.gasp_based.idle_descent_estimation import add_descent_estimation_as_submodel
from aviary.mission.gasp_based.idle_descent_estimation import (
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Doing the auto-PEP on this file might make it very difficult to merge the changes into the level 2 refactor that is part of the epic that Eliot is working on.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This PR isn't time sensitive, I don't mind waiting until after that work gets merged in

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants